《Cursor 高阶使用手册（Java 后端工程师版）》

特别说明：此文由ChatGPT生成，后续由我本人编辑、修改而成。

1 核心理念：思考与执行分离

没有人会让建筑工人一边砌砖一边设计图纸。这个道理显而易见：设计需要全局视野和反复推敲，施工需要专注细节和高效执行——两种工作模式截然不同，混在一起只会两头都做不好。建筑行业早就想明白了这一点，所以有了建筑师和施工队的分工。软件开发也是如此，在使用 Cursor 时，你应当将问题推理和代码编写明确区分开来——先让 AI 帮你规划解决方案，确认无误后，再让它执行编码。

Cursor 为此提供了两种模式：Plan 模式是你的”作战室”，在这里与 AI 讨论思路、澄清需求、制定计划，让它复述你的要求，给出实施步骤，甚至画出架构草图；Agent 模式是你的”施工队”，一旦方案敲定，Agent 会按照计划自主探索项目、修改代码，像一个勤勉的工程师那样完成任务。

一个典型的协作流程

假设你要实现一个用户积分系统。错误的做法是直接告诉 Cursor：”帮我实现用户积分功能”，然后看它自由发挥。正确的做法是分两步走：

第一步：Plan 模式讨论方案

我需要实现一个用户积分系统，包括积分获取、消费和查询功能。请先不要写代码，帮我分析一下：

1. 需要哪些数据表？
2. 需要哪些接口？
3. 有哪些边界情况需要考虑？

Cursor 可能会回复：需要 user_points 表记录余额，points_record 表记录流水；需要考虑并发扣减的原子性问题；建议使用乐观锁或数据库事务… 你审核这个方案，发现它漏掉了积分过期的需求，于是补充：”积分有有效期，需要支持过期自动失效。”

第二步：确认后切换 Agent 模式执行

方案敲定后，告诉 Cursor：”方案确认，请按照上述设计实现代码。”Agent 会根据之前讨论的方案，自动创建实体类、Mapper、Service 和 Controller。这个”复述仪式”看起来多了一步，但它能避免方向性错误，省去大量返工。

中间产物：你们之间的”合同”

如果任务复杂，不妨要求 AI 先输出一份 Markdown 格式的设计方案。这份中间产物就是你们之间的”合同”：

请把刚才讨论的积分系统设计整理成一份 Markdown 文档，包括数据表结构、接口定义和关键逻辑说明。保存为 docs/积分系统设计.md。

确认文档无误后，后续的编码就有了明确的依据。即使中途会话中断，这份文档也能帮助你快速恢复上下文。在 Chat 思考阶段，你是架构师，与 AI 一起推演方案；在 Agent 执行阶段，AI 是工程师，负责落实细节。这种分工不仅适用于软件开发，也适用于任何需要先想清楚再动手的工作。

2 多轮对话技巧

2.1 分支选择：在岔路口做出正确的决定

下棋的人都知道，一盘棋的胜负往往取决于几个关键的分支选择，走错一步，后面再怎么努力都难以挽回。与 AI 对话也是如此——面对复杂任务，Cursor 可能会提出多种方案，或者在执行过程中出现不同的分支路径，你的任务是在这些岔路口做出正确的选择。

实战案例：选择缓存方案

你让 Cursor 为热点数据添加缓存，它可能会提出三种方案：1) 使用 Spring Cache + Redis；2) 使用 Caffeine 本地缓存；3) 使用 Guava Cache。这时不要急着让它实现，先问清楚每个方案的优缺点：

请分析这三种缓存方案的适用场景、优缺点和性能差异，帮我选择最合适的方案。我们的场景是：QPS 约 1000，数据更新频率较低，需要支持集群部署。

Cursor 会解释：本地缓存性能最好但不支持集群同步，Redis 支持集群但有网络开销… 根据你的场景，它可能建议使用两级缓存：本地缓存 + Redis。这种”先问方案，再选择，最后执行”的模式，能避免在错误的技术路线上浪费时间。

2.2 链式思考：让 AI 一步一步推理

1956年，认知心理学家乔治·米勒发表了著名论文《神奇的数字7±2》，揭示了人类工作记忆的容量限制。有趣的是，大语言模型也面临类似的挑战——当问题足够复杂时，一步到位往往会出错。解决办法是链式思考（Chain-of-Thought）：让 AI 逐步分析问题，而不是直接给出最终答案。

实战案例：排查 NPE 异常

当你遇到一个难以定位的空指针异常，可以这样提示：

项目启动时报 NullPointerException，堆栈信息如下：[粘贴堆栈]

请使用链式思考方法分析：

1. 这个异常发生在哪一行？
2. 哪个变量可能为 null？
3. 这个变量是在哪里被赋值的？
4. 为什么在这个时机它可能还没被赋值？
5. 应该如何修复？

AI 会按步骤分析：异常发生在 UserService 第 42 行，userRepository 为 null，它应该通过 @Autowired 注入，但可能因为循环依赖导致注入失败… 这种逐步推理比直接问”怎么修”更容易找到根本原因。

2.3 保持目标一致性：别让 AI 跑偏

心理学家丹尼尔·卡尼曼在《思考，快与慢》中描述过一种现象：人们在解决复杂问题时，常常不知不觉地偷换了问题本身。AI 也有类似的倾向——它可能在推理过程中逐渐偏离你的真正目标。

实战案例：优化查询性能

你让 Cursor 优化一个慢查询，它可能会热情地重构整个数据访问层，引入新的 ORM 框架，甚至建议更换数据库… 这时要及时拉回来：

停一下。我的目标只是优化这一个查询的性能，不需要重构整个数据层。请聚焦在：

1. 分析当前 SQL 的执行计划
2. 建议合适的索引
3. 优化 SQL 写法

其他架构调整不在本次范围内。

如何防止跑偏？经常性地在提示中重申最终目标或关键约束；每轮回复后，先验证思路是否仍围绕目标；必要时直接纠偏：”请关注 XXX 目标，不要偏离 YYY 方面”。就像长途旅行需要不断核对地图，与 AI 的长对话也需要反复校准方向。

2.4 绕开错误链路：及时止损

有时候你会发现，Cursor 正沿着一条错误的道路推理——可能是误解了需求，也可能是采用了不合适的技术方案。这时最重要的是及时止损，不要试图在错误的基础上修修补补，那只会越陷越深。

实战案例：事务处理的误区

你让 Cursor 实现一个订单创建功能，它生成的代码在循环中逐条插入订单明细，没有使用事务。你指出问题后，它加了 @Transactional，但注解加在了私有方法上（这在 Spring 中不生效）。这时不要继续在这个方向上修补，而是重新开始：

刚才的实现有事务问题。让我们重新来：

1. 首先，请说明 Spring 事务的正确使用方式
2. 然后，重新设计这个订单创建流程，确保原子性
3. 考虑异常情况下的回滚策略

具体怎么做？首先澄清问题或需求，消除 AI 可能的误解；明确指出之前方案的问题；必要时缩小问题范围，从更基础的问题开始，逐步建立正确的推理链路。你还可以通过 .cursorrules 文件来限制 AI 的修改范围与风格。一旦发现错误趋势，立即重置思路或回滚——在错误的路上走得越远，回头的代价就越大。

3 提示词模板

语言学家沃尔夫提出过一个著名假说：我们使用的语言，会影响我们思考的方式。在与 AI 协作时，这一假说同样适用——你如何表达需求，直接决定了 AI 如何理解和执行。下面是几个经过验证的提示词模板，专为 Java 后端开发者设计。

3.1 “先画接口，不要写代码”

建筑师不会在画完图纸之前就开始砌砖。同样，开发新模块时，你可以这样提示：

我需要实现一个商品库存管理模块，包括：查询库存、扣减库存（需要支持批量）、库存预警通知。

请先设计接口：

1. Controller 层的 API 定义（路径、方法、参数、返回值）
2. Service 层的方法签名
3. 请求和响应的 DTO 类结构

不要写实现代码，我们先确认设计。

Cursor 会输出清晰的接口蓝图，你确认设计合理后再让它生成实现。这一策略体现了推理与编码分离的思想——代码落地前，先确保设计经过充分推演。

3.2 “伪代码先出”

当实现复杂功能时，直接写代码容易陷入细节。不如先让 AI 产出伪代码：

我需要实现一个分布式锁服务，基于 Redis。请先用伪代码描述实现思路：

1. 加锁的流程（包括重试机制）
2. 解锁的流程（包括防止误删其他线程的锁）
3. 锁续期的机制

用中文注释写清楚每一步的逻辑，确认无误后再填充具体代码。

这就像先写提纲再写文章。Cursor 会先给出详细的步骤说明，你审核伪代码确认无误后，再让它填充细节。两阶段输出，能大幅减少来回修改。

3.3 “先别急着写”

这是一个简单但极其有效的模板：

我需要实现一个定时任务，每天凌晨2点清理30天前的日志数据。清理时要分批删除，避免锁表。同时要记录清理结果，如果失败需要告警。

在写代码之前，请先复述一下你理解的需求，确保我们在同一页面上。

Cursor 会用自己的话总结需求，你可以校验它的理解是否正确。如果有误解可以立即纠正。这就像医生在手术前确认患者信息——一个小小的确认步骤，可以避免方向性错误。

3.4 “逐步求精”

优化代码时，一步到位的重构往往风险很高。不如让 AI 渐进式改进：

下面这段查询代码性能较差，请逐步优化：

[粘贴代码]

要求：每次只做一项改进；解释改进的原因和预期效果；保持原有接口不变；等我确认后再进行下一步。

Cursor 可能会这样回复：”第一步优化：将循环内的数据库查询改为批量查询。原因：当前代码在循环中逐条查询用户信息，N 次循环就有 N 次数据库往返，改为批量查询后只需 1 次。” 你确认后，它再进行第二步优化。每次改动都在掌控之中，也方便定位问题。

3.5 “禁止使用某技术/库”

如果项目有技术选型限制，可以直接告诉 AI：

实现时请遵守以下约束：

• 不要使用 Lombok（项目未引入）
• 不要使用 Java 8 以上的语法特性（兼容性要求）
• 不要直接操作 Thread，使用线程池
• 不要硬编码配置值，使用 @Value 注入
• 不要使用 System.out.println，使用 Logger

通过列出禁止事项，可以有效防止 AI “越界”，确保生成的代码符合项目规范。

3.6 “对比分析”与“代码审查者视角”

当你不确定该选哪种方案时，可以要求对比分析：

请对比分析以下两种实现方式的优缺点，并给出推荐：
方案A：使用消息队列异步处理
方案B：使用 @Async 注解异步处理

从以下维度分析：可靠性、复杂度、可观测性、运维成本

也可以让 AI 扮演代码审查者：

请以高级工程师的视角审查以下代码，指出：潜在的 bug 或边界情况、性能问题、安全漏洞、代码规范问题、可维护性改进建议。

建议：团队可以沉淀自己的高频 Prompt 库，将常用场景（登录认证、CRUD 接口、分页查询等）的提示整理成模板。新人也能快速上手，提示越清晰结构化，AI 输出就越准确。

4 Java 后端场景专用技巧

4.1 接口设计：先契约，后实现

在微服务架构中，接口就是服务之间的”合同”，合同写得不清楚，后面就会纠纷不断。使用 Cursor 进行接口设计时，最佳实践是先编写接口规范，再写实现——让 Cursor 根据需求文档先输出接口设计草图（类名、方法名、参数和返回值、HTTP 路径和动词），然后由你审核调整，最后再生成实现代码。

提示词示例：

根据以下需求，设计用户管理模块的接口（方法签名和请求/响应结构），先不要实现代码：

功能需求：用户注册（邮箱、密码、昵称）、用户登录（返回 JWT token）、获取当前用户信息、修改用户资料。

设计要求：RESTful 风格；统一响应格式 {code, message, data}；需要考虑参数校验注解。

对于需要与前端对接的 API，Cursor 还能生成接口文档说明，帮助前后端对齐契约。接口设计阶段多花的时间，会在后续开发中成倍节省。

4.2 数据库操作：MyBatis 与 JPA

数据库操作是后端开发的核心。Cursor 可以帮你快速生成 Mapper 和 Repository 代码，但需要明确告诉它你使用的技术栈。

MyBatis 场景：

根据以下表结构，生成 MyBatis 相关代码：

CREATE TABLE t_order (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    order_no VARCHAR(32) NOT NULL,
    user_id BIGINT NOT NULL,
    total_amount DECIMAL(10,2),
    status TINYINT DEFAULT 0,
    created_at DATETIME,
    updated_at DATETIME
);

请生成：Order 实体类（使用驼峰命名）、OrderMapper 接口（包含 CRUD 和按用户ID查询）、OrderMapper.xml 文件、复杂查询使用动态 SQL。

JPA 场景：

使用 Spring Data JPA，根据上述表结构生成：Order 实体类（包含 @Table、@Column 注解）、OrderRepository 接口、包含自定义查询方法（按状态统计、按时间范围查询）、使用 @Query 注解的复杂查询。

4.3 Filter 链路控制与异常处理

Web 应用中的过滤器链路，就像流水线上的工序——顺序错了，产品就废了。添加新过滤器时，要明确告诉 Cursor 它在链路中的位置：

请创建一个新的过滤器 AuditFilter，用于记录请求日志，插入到 SecurityFilter 之后执行。需要记录：请求路径、方法、参数；响应状态码、耗时；用户 ID（从 SecurityContext 获取）；异常信息。日志格式使用 JSON，方便后续分析。

对于异常处理，优雅的统一封装是后端服务成熟度的标志：

请实现一个全局异常处理机制：

1. 创建统一响应类 Result，包含 code、message、data 字段
2. 创建业务异常类 BusinessException，包含错误码枚举
3. 创建全局异常处理器，处理 BusinessException、MethodArgumentNotValidException、其他未知异常
4. 错误码枚举至少包含：SUCCESS、PARAM_ERROR、UNAUTHORIZED、FORBIDDEN、NOT_FOUND、SYSTEM_ERROR

需要注意的是，AI 生成的业务逻辑有时会忽略安全细节——比如登录代码可能缺少密码加密。这些细节需要在提示中明确要求，或在代码生成后手动检查补充。

4.4 单元测试与性能优化

让 Cursor 帮你生成测试代码：

为以下 Service 类生成单元测试：[粘贴 Service 代码]

要求：使用 JUnit 5 + Mockito；Mock 所有依赖的 Repository 和外部服务；覆盖正常流程和异常流程；边界条件测试（空值、极限值）；使用 @DisplayName 注解描述测试场景；遵循 Given-When-Then 模式。

让 Cursor 帮你分析性能问题：

以下接口响应时间达到 2 秒，请帮我分析可能的性能瓶颈：[粘贴代码]

请从以下角度分析：数据库查询（N+1 问题、缺少索引、全表扫描）；循环中的重复计算或 IO 操作；可以并行化的操作；可以缓存的数据；不必要的序列化/反序列化。

4.5 Request/Response 契约定义

前后端协作中，数据格式的约定往往是沟通成本最高的环节。Cursor 可以帮你快速定义 DTO/VO 类：

请求包含 userName 和 password 两个字段，返回结果包含 userId、token 和过期时间，请定义相应的请求和响应类。

要求：添加参数校验注解（@NotBlank、@Size 等）；添加 Swagger 注解描述字段含义；敏感字段（如密码）在日志中脱敏。

使用 Cursor 定义契约的好处是速度快且格式统一。但前提是你的描述足够清晰——AI 无法凭空猜测业务含义，字段用途、类型约束这些信息，都需要你提供。

5 代码重构策略

5.1 指定局部修改：手术刀而非大锤

重构代码时，最怕的是牵一发动全身——让 AI 修改一个方法，结果它把整个类都重写了，这种事并非没有发生过。如何避免？使用选区编辑：在编辑器中选中需要修改的代码片段再提问，AI 的作用范围就局限在选中部分；在提示词中明确限定范围；使用 @file 引用特定文件。

明确边界的示例：

请仅修改 OrderService.createOrder 方法中的库存扣减逻辑：

• 当前是先查询再更新，存在并发问题
• 请改为使用乐观锁（版本号）方式
• 不要修改方法签名
• 不要修改其他方法
• 不要修改 OrderMapper

Manual 模式下，AI 会严格执行你的指令。若 AI 产出修改超出范围，及时撤回并重新强调边界。

5.2 使用 diff 审核：每次修改都要过目

Git 的发明者林纳斯·托瓦兹有句名言：”Talk is cheap. Show me the code.”在与 AI 协作时，这句话可以改成：”Show me the diff.” 每次让 AI 修改代码后，都应该要求它输出变更摘要或 diff，尤其在 Agent 模式下进行跨文件修改，更要逐一对比原始代码和修改后的区别。

审核清单：是否有意外删除的代码？是否有意外添加的依赖？变量名、方法名是否被意外重命名？是否修改了不应该动的文件？格式变化是否过多？逻辑是否与预期一致？

养成先 diff 审核再接受修改的习惯，相当于给 AI 的每次”提交”都做一次代码评审。

5.3 避免格式化污染

有时 AI 修改代码会顺带调整格式、缩进、import 语句，导致大段无关变动，给代码审查和合并带来不必要的困扰。几种策略：在提示词中明确要求”不修改代码风格和格式”；分步进行，先让 AI 修改逻辑，确认无误后再单独处理格式；使用 .cursorrules 文件指定代码风格约束。

.cursorrules 示例：

# 代码风格约束
- 使用 4 空格缩进，不使用 Tab
- 大括号不换行（Java 风格）
- import 语句按字母顺序排列
- 不要自动优化 import
- 保持原有的空行风格
- 不要添加或删除注释（除非明确要求）

一旦发现 AI 输出中有大段格式改动，退回上一步并强调”保持原代码格式不变，仅做必要改动”。目标是让每次提交尽可能小而集中。

5.4 多文件协作：渐进式推进

重构经常涉及多个文件的同步修改——方法签名改了，调用它的地方也要跟着改。Cursor Agent 模式可以跨文件全局重构，但务必验证所有相关文件都正确更新。稳妥的做法是分步骤多文件修改：

我需要将 UserService.getUser(Long id) 方法重命名为 getUserById(Long id)。请按以下步骤执行：

1. 首先列出所有调用这个方法的文件
2. 修改 UserService 中的方法名
3. 逐个修改调用方，每修改一个文件后暂停等我确认
4. 最后检查是否有遗漏

这种渐进式协作可以与 Cursor 的任务切换功能相结合：完成一组文件的修改后，使用 /newtask 开启新任务，处理下一组相关文件。切换时让 AI 总结前一任务成果，保证上下文连贯。

6 项目协作与上下文管理

6.1 使用 .cursorrules 定义项目规范

.cursorrules 文件是 Cursor 的规则配置文件，放在项目根目录，可以告诉 AI 这个项目的技术栈、编码规范和特殊约束。

Java 后端项目的 .cursorrules 示例：

# 项目概述
这是一个基于 Spring Boot 2.7 的电商后端项目。

# 技术栈
- Java 11、Spring Boot 2.7.x、MyBatis Plus、MySQL 8.0、Redis、RabbitMQ

# 编码规范
- 使用阿里巴巴 Java 开发手册规范
- Controller 层只做参数校验和结果封装，业务逻辑放在 Service 层
- 使用 @Slf4j 记录日志，不使用 System.out
- 异常使用自定义 BusinessException，不要直接抛出 RuntimeException
- 数据库字段使用下划线命名，Java 属性使用驼峰命名

# 项目结构
controller/、service/、mapper/、entity/、dto/、vo/、config/、util/

# 禁止事项
- 不要使用 Lombok（项目未引入）
- 不要使用 Java 8 以上的语法
- 不要在循环中进行数据库查询
- 不要硬编码配置值

有了这个文件，Cursor 在生成代码时会自动遵守这些规范，大大减少后期修改。

6.2 多人协作与上下文传递

人类团队协作的核心挑战之一是知识的传递。新人接手项目时，最痛苦的往往不是代码本身，而是理解”为什么这样写”的上下文。与 AI 协作也面临类似问题：如何让下一位开发者（或下一次会话）理解之前的工作？

一个有效的方法是维护一个 progress.md 或 project-status.md 文件。在每次会话结束时，让 Cursor 将完成的功能、遇到的问题和解决方案写入其中：

本次会话结束时，将你的工作日志记录在 @project-status.md 文件中，包括：已实现的功能点、修改的文件清单、遇到的问题和解决方案、未完成事项和后续计划、需要注意的技术债务。

这样，当另一位同事接手时，只要查看这个文件，就能了解上一开发环节做了什么。把这些日志文件纳入版本控制，实际上就是把 AI 对话的精华持久化了。

6.3 版本控制对话与快速上下文重建

除了文本日志，一些团队还会将重要的对话导出为 Markdown 记录，存入项目文档。这可以视为某次 AI 辅助开发的”剧本”——日后查阅，可以明白当初 AI 和开发者是如何一步步做出决策的。对话记录的价值包括：技术决策的依据、问题排查的线索、新人培训材料、审计追溯。需注意对话记录中可能包含敏感信息，在公开之前要做好筛查或脱敏处理。

会话长度受限或意外中断时，如何让 AI 快速恢复上下文？如果之前有维护 project-status.md，新会话开始时直接将该文件提供给 AI：

请阅读以下文件了解项目上下文：

• @.cursorrules：项目规范
• @project-status.md：当前进度
• @docs/积分系统设计.md：相关设计文档

上次我们完成了积分获取功能，今天继续实现积分消费功能。

Cursor 读取这些文件后，就相当于”记起”了项目当前状态和最近进展。建议每次会话结束都记录详细报告——这正是为下次重建上下文做的准备。

7 高阶自动化流

7.1 结构化任务：让 AI 按清单执行

软件工程师阿图·葛文德在《清单革命》中写道：面对复杂性，清单是最有效的武器。这一洞见同样适用于与 AI 的协作。Cursor Agent 模式可以将复杂任务拆解为结构化的子任务列表，并按序自动执行。

实战示例：开发一个完整功能

请按以下任务清单开发”用户收货地址管理”功能：

任务清单

• 1. 设计数据表结构（用户地址表）
• 2. 创建实体类和 Mapper
• 3. 设计 API 接口（增删改查 + 设为默认）
• 4. 实现 Service 层逻辑
• 5. 实现 Controller 层
• 6. 添加参数校验
• 7. 编写单元测试
• 8. 添加 Swagger 文档

请逐项执行，每完成一项更新清单状态，并等待我确认后再继续下一项。

Agent 会边执行边维护任务列表，每完成一项就勾掉并继续下一项。开发者可以在执行过程中插手调整——修改顺序、增加遗漏的步骤。

7.2 组合与拆分：灵活调度任务流

并非所有任务都适合线性执行。有时一个大任务需要拆分为并行的几部分，有时多个小任务可以合并一起做。Cursor 的 Plan 模式可以帮助制定任务拆解策略：

我需要开发一个”订单导出”功能，支持导出为 Excel 和 PDF。请帮我拆解任务：哪些部分可以并行开发？哪些部分必须按顺序？预计有哪些技术难点？建议的开发顺序是什么？

Cursor 可能会建议：并行部分（Excel 导出实现、PDF 导出实现）；顺序部分（先实现通用的查询逻辑，再实现具体的导出格式，最后做异步导出和进度反馈）；技术难点（大数据量导出需要分页处理，PDF 中文字体需要额外配置）。通过合理的拆解和组合，可以最大程度发挥 AI 的并行处理能力，让复杂任务流转更为顺畅。

7.3 中间产物：在流水线上设置检查点

在工业生产中，质量控制的关键是在流水线上设置检查点——不是等产品完成后才发现问题，而是在每个关键环节都进行检验。与 AI 协作的自动化流程也应如此，在最终代码生成前，要求 AI 产出一些过渡性的结果供审核。

常见的中间产物：

阶段	中间产物	用途
需求分析	需求确认清单	确保理解无误
方案设计	设计文档	确认技术方案
接口设计	API 定义文档	前后端对齐
编码前	伪代码	确认实现思路
编码后	变更清单	审核改动范围
测试前	测试用例设计	确认测试覆盖

归纳来说，高阶自动化流程并不意味着让 AI 一股脑完成所有事情。真正的效率来自于规划 → 核对 → 执行的循环：以中间产物作为检查点，串联起整个流水线。最终，我们获得的是一个由 AI 辅助运行的开发流程——既有分阶段的清晰产物，又能快速迭代。

结语

1997年，国际象棋世界冠军卡斯帕罗夫输给了 IBM 的深蓝计算机。这场对决之后，卡斯帕罗夫提出了一个新概念：”人机协作棋”——人类棋手与计算机组队，往往能击败单独的人类或单独的计算机。今天，我们与 Cursor 的协作正是这一理念的延续。AI 擅长的是速度、记忆和生成力；人类擅长的是判断、创意和把关。两者结合，能完成任何一方单独无法完成的任务。

本文介绍的技巧可以总结为几个核心原则：思考与执行分离——先在 Plan 模式讨论方案，确认后再用 Agent 执行；多轮迭代优于一步到位——让 AI 逐步推理、逐步改进，而不是一次性给出结果；中间产物即检查点——要求 AI 输出设计文档、伪代码等中间结果供审核；明确边界与约束——通过提示词和 .cursorrules 限定 AI 的行为范围；持久化 AI 的记忆——通过 progress.md 等文件实现上下文传递。

掌握这些技巧，你就能与 Cursor 搭档完成更复杂的开发任务。在实践中不断总结经验、完善提示词模板库，善于利用 Cursor 的新功能拓展能力边界。最终，AI 不是来取代你的，而是来放大你的。愿本手册能帮助你在日常开发中游刃有余，让 Cursor 成为真正的编程拍档，共同创造出更健壮优秀的后端系统。